I am implementing a custom generic spatial accessory according to Section 20 of the Accessory Design Guidelines dated 2026-06-08. Apple Vision Pro discovers the accessory, completes BLE pairing and encryption, reads the Apple Spatial Accessory Version and Uniform Type Identifiers characteristics, and recognizes the device in the accessory tracking debug view. However, visionOS writes ASA protocol version 00.00 to the Apple Spatial Accessory Host Version characteristic instead of selecting version 01.01. Here is the log message when I connected my spatial accessory with apple vision pro with os27 beta 3. The error is the ASA part. BLE advertising: ZemScannerASA15; BLE ATT MTU tx=23,rx=23; BLE conn timing connected: interval=30000; us,latency=0,timeout=72; TimeSync anchor report enabled: h=0x011f; BLE connected TimeSync anchor #1 ce=0,int=30000,delay=0 TimeSync anchor #2 ce=3,int=30000,delay=0 TimeSync anchor #3 ce=4,int=30000,delay=0 BLE ATT MTU tx=293,rx=65 BLE security level 2 BLE pairing complete, bonded ASA version read #1 off=0 req=64 hex=02 01 01 01 01 ASA UTI read #2 off=0 req=64 total=49 ASA host wr #3 o=0 l=4 f=00 hex=00 00 01 31 ASA host raw: off=0,write=4,total=4,hex=00 00 01 31 ASA host version: >len=4,ver=0.0,features_len=1,features=0x31 ASA host selected no common protocol HID direct input report sent HID notif #4 report=3 enabled HID IMU stream started HID notif #5 report=2 enabled HID IMU report sent BLE conn params updated: interval=7500 us,latency=4,timeout=100

Hi guys! I wanted to study this new ManipulationComponent(), but I keep getting a warning that I don’t understand, even in a very simple scenario. i don't have any collisions just binding the Manipulation the warning message is : ** Entity returned from EntityWrapper.makeEntity(context:) was already parented to another entity. This is not supported and may lead to unexpected behavior. SwiftUI adds entities to internally-managed entity hierarchies.** RealityView { content, attachments in if let loadedModel = try? await Entity(named: "cloud_glb", in: realityKitContentBundle) { content.add(loadedModel) loadedModel.components.set(ManipulationComponent()) } Thanks !

This was confirmed as a framework gap in an accepted answer from an Apple Vision Pro engineer in June 2024 (https://developer.apple.com/forums/thread/758014?answerId=792769022#792769022): .background fires identically whether the user taps a window's close button or the system backgrounds a window that's been out of the field of view for ~61 seconds, and there's no app-visible signal that distinguishes the two. The recommendation at the time was to use a gesture/affordance to reopen the window, and to file an enhancement request. Two years on, with the window-management APIs that have shipped since, I want to confirm whether the situation has changed as of visionOS 26. My case: VisionBlazer, a native spatial 3D creation tool (TestFlight beta, August 2026 launch). Users routinely work with several SwiftUI WindowGroup tool windows open at once — drawing tools, materials, timeline, properties, lighting — parked spatially around an ImmersiveSpace. Parking a window behind or beside you is core to the workflow. The app should terminate when the user closes the primary window, but must not terminate when a secondary window (or the primary) is simply parked out of view. What I've verified on-device (visionOS 26.5): scenePhase == .background fires identically for a user close tap and for the ~61s out-of-FoV backgrounding (SurfBoard: "…is out of FOV after 60.99 seconds. Backgrounding"). The phase sequence (active → inactive → background) and timing (~0.2–0.4s gap) are indistinguishable between the two cases. scenePhase on visionOS reflects visibility, not focus — a parked window stays .active while the user edits elsewhere, until the out-of-FoV timer fires. The session identifier reachable from the window's view hierarchy (view.window!.windowScene.session.persistentIdentifier) never matches the identifier reported by application(_:didDiscardSceneSessions:) or UIScene.didDisconnectNotification for that same close. The view-visible session stays in UIApplication.shared.openSessions indefinitely after the close. Those disconnect/discard callbacks arrive ~10–15s late and only ever carry foreign session identifiers, so they can't be attributed to a specific window. Stale-session discards from prior launches pollute the signal further. onDisappear does not fire on user close. Five strategies tried, all failed: (1) scene-object identity captured at didMoveToWindow; (2) session.persistentIdentifier matching against openSessions; (3) live re-capture of scene/session from the view hierarchy on every lifecycle change; (4) temporal correlation of didEnterBackground/didDisconnect; (5) a focus-recency heuristic on scenePhase transitions. All fail on the identifier mismatch and the visibility-not-focus semantics above. Questions: As of visionOS 26, is there now any supported way to detect that the user intentionally closed a specific window, distinct from system backgrounding? Is there a SwiftUI or scene-delegate callback tied to a window's own scene that fires only on user close? Is there a dismissalReason (or equivalent) anywhere on the close path? If none of the above exists, is an explicit in-app Quit button still the intended pattern for "quit when the main window is closed"? I have a focused test project reproducing all of this and can link it. Thanks.

If a ViewAttachmentComponent moves into frame, it is low resolution until something changes the view while it is in frame. Video demonstrating the behavior: https://youtu.be/KXEFFiAnv1s I am on visionOS 27 beta 4. This did not occur when I was on visionOS 26.5. Also using Xcode 27.0 beta 4 and macOS 27.0 beta 4. To reproduce, have a ViewAttachmentComponent in an immersive space, look away, then look back, and it'll be low resolution. Anything which would change the view while it's in frame will then cause it to update in full resolution. Screenshot of low-resolution view after it moves back into frame from being out of frame: Screenshot after updating the view, making it high-resolution again: I've submitted feedback as FB24116473.

With Xcode Version 26.5 (17F42) apps can no longer be launched on a real Vision Pro once migrated to visionOS 27 Beta 2. At launch there is an EXC_BAD_ACCESS runtime error in an initialiser. If you launch apps on a real iPhone/Ipad with OS 27 Beta 2 the program will stop before the end of its start, but there is no precise line with the error. Xcode just stop in assembly code in the debugger, in the init phase of Swift where it searches for which objects to instantiate at launch. After investigating, the error comes from a debug setting from Xcode to show the stack trace. To avoid the error when run from Xcode Version 26.5 (17F42) In Xcode, open Product > Scheme > Edit Scheme. Select the Run action in the sidebar, then open the Options tab. Find Queue Debugging and uncheck Enable backtrace recording. If Queue debugging is enabled, then the program crashes when launched It is useful to be able to run apps from the production Xcode to devices with 27 OSes in beta to be able to test that everything will work fine for new versions of apps released before OSes 27 release. Thank you A previous post was made but the cause was badly identified. New Feedback including a sample code FB23384318

I am trying to view immersive environments that are Gaussian Splats created by marble [dot] worldlabs [dot] ai. For example, here is one named "Steampunk City Night View": (Note: the low-res version is 500,000 splats, so I am just testing the first 200,000 splats). But when I try to view it at scale, nothing appears. I tried shrinking it down (scale factor of 0.00595458) and positioning it in front of me, and I could see the content, so the parsing of the PLY file is working. Example: But when I move into the model, it goes clear, also hiding virtual content behind it that is also in the splats' space (like the Mac virtual screen). Example: It is as if when I move inside the Gaussian Splats' bounding box, it sets an opacity material on the splats. This prevents me from using these Gaussian Splats as immersive environments. Is there any way to disable this behavior?

Hi, I’m running into an issue when importing a .usdz asset into Reality Composer Pro 3. The exact same asset was working perfectly in Reality Composer Pro 2, and it also works correctly when previewed in Xcode 27.0 beta or loaded directly in RealityKit from code. However, in Reality Composer Pro 3, the asset does not import correctly: The material appears completely broken and looks different from the original asset. The animations are not working. The same .usdz works as expected in Reality Composer Pro 2, including materials and animations. The same .usdz also works as expected in Xcode / RealityKit. I also noticed that the Preview app does not seem to import the asset correctly either. In Preview, the asset has the wrong orientation and it looks like the skeleton and animations may not be recognized properly. Here are a few screenshots showing how the asset appears in each app: Reality Composer Pro 2: asset works correctly, including materials and animations. Xcode 27.0 beta preview: asset works correctly, including materials and animations. Reality Composer Pro 3: material is broken and animations are not working. Preview app: wrong orientation, possible skeleton / animation import issue. I filed a ticket FB23214120 that contains an example Xcode project and RCP2 & RCP3 projects. Is there anything specific that changed in the USDZ import pipeline in Composer Pro 3 that could explain this behavior? Thanks!

From visionOS 2.0 we can access Apple Vision Pro's main camera but only for Enterprise account as it is enterprise API only, I have a normal Developer account and I want to use main camera and want to have a video call feature in app by using main camera of AVP, is it possible to do it using developer account only. Currently using that account I am not able to create entitlement certificate as there is no option.

Many apps utilize ImmersiveSpace simply to render large-scale, custom geometry (such as curved screens, wide-canvas media players, or specialized data visualizations) that cannot be achieved within a standard volumetric window limitations. However, users often still want to multitask—check Messages, reference Safari, access YouTube, etc. Forcing the user to exit the immersive space just to see their other apps breaks their workflow and creates a disjointed user experience. Proposed Solution: I propose adding a property to ImmersionStyle (or a similar API configuration) such as allowSharedSpaceVisibility. When enabled, this would: Allow the ImmersiveSpace to render its custom RealityKit content as usual and prevent the system from automatically hiding the user's existing Shared Space windows. Do me a solid here VisionOS team and please consider this feedback request. 🙏 FB: FB22973973 FB: FB21630340

Hi, several WWDC26 sessions this year feature the Chaparral Village project. However, I can't find a download for it anywhere. Will the Chaparral Village project be published as downloadable sample code? Thanks!

Building Dasher (eye-gaze text-entry system for people with motor impairments — ALS, cerebral palsy, etc.) for visionOS. See https://github.com/dasher-project/Dasher-Apple The app needs continuous (x, y) gaze coordinates to steer a zooming alphabet interface. Vision Pro has incredible eye tracking hardware built in — this should be the perfect platform — but I can't get gaze coordinates through any API I've tried. What I've tested (all deliver zero events in a windowed app): UIHoverGestureRecognizer — Apple's docs say it "detects when the user is looking at a view" on visionOS. Added it to a UIView inside UIViewRepresentable. Looked at the view for 2+ minutes on real hardware. Console.app shows zero began/changed/ended callbacks. .onContinuousHover (SwiftUI) — zero .active phases delivered, whether attached to the canvas view or the ZStack root. UIPointerInteraction with a delegate — regionFor callback never fires. The system clearly is tracking gaze — I can see beginScrollingWithRegion events in Console.app with the correct window rect, and the visual hover highlight appears on buttons. But the coordinates are routed to scroll handling, not exposed as a usable pointer position. What does work: pinch-and-drag follows the hand position (where the pinch is in 3D space), not gaze. That's fine for general apps but doesn't help users who need eye-only control. What I'm wondering: Has anyone successfully received continuous gaze coordinates in a windowed (non-immersive) visionOS app? If so, which API? Is UIHoverGestureRecognizer supposed to work on UIView inside UIViewRepresentable, or does it require a pure UIKit view hierarchy? Is there an ARKit provider for eye tracking that I'm missing? I see HandTrackingProvider but no EyeTrackingProvider in the capability list. Could the issue be that my SwiftUI overlay (toolbar VStack) is intercepting hover events before they reach the canvas underneath? If so, how do you make a SwiftUI overlay pass-through for hover? Dasher is a well-established accessibility tool that lets people type using only their eyes. Its the fastest text entry method for eyegaze and head controlled systems. On every other platform (iOS with external trackers, Windows with Tobii, etc.) it reads continuous gaze coordinates and zooms toward wherever the user is looking. Vision Pro should be the best hardware for this — the tracking is already there, we just can't read it. If there's no public API for this, I'd love to know so I can scrap my feedback assistant entry!. If there IS a way and I've missed it, I'd be grateful for a pointer. Thanks!

In visionOS 2, the system search displays the icon of each App Entity registered. It used to work up to visionOS 26 beta 7. But since visionOS 26 beta 8, visionOS 26.x , and still in the current visionOS 27 Beta 2 the system search no longer display the right icon. Instead it displays the icon of an AppShortcut declared by the source code which uses the AppEntities. This does not help the users to find the right AppEntity in a search with multiple results as they all have the same AppShortcut icon. This "bug" also make the search result differ from the experience with iOS and iPadOS which display each AppEntity icon. You can use the Apple sample to see this bug on visionOS 27 Beta 2 and 26. Accelerating app interactions with App Intents AppEntities are an important part of Apple Intelligence, the system integration is really important for a great user experience. FB19915478

How do I snap a window to a surface in the visionOS Simulator?

The link to download “MaterialX definitions” is broken on the main page of ShaderGraph documentation in the Interoperability section. See here: https://developer.apple.com/documentation/ShaderGraph#Interoperability Link in the page is https://developer.apple.com/augmented-reality/realitykit/files/MaterialX-definitions.zip but leads nowhere now. Since Reality Composer Pro 3 has been released, it would be good to have these definitions available to download again and to know if it’s still MaterialX 1.38 being used in the updated RCP & RealityKit. Opened a ticket about this: FB23258836

With visionOS 27, if you use a non US Apple ID, if the language is set to English on the country to USA, you don’t get Siri AI even if Siri AI is supposed to be available on visionOS 27 in all countries if the system is in English. iOS and iPadOS are the only systems where Siri AI is not available in Europe. As macOS, visionOS is supposed to have Siri AI enabled worldwide if the system is configured in English. The problem is confirmed with many French Vision Pro users with a French Apple ID. Feedback: FB23207278

visionOS 26.5, xcode26.5 - app terminated with exit code 9 then crashed and rebooted the entire device (Apple Vision Pro). I was connected to the Xcode debugger when this happened, and it didn't crash in any of our code. Memory and CPU usage was low at the time. Any idea what could be causing the issue? Some logs: << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 ... Call start on AVKSDockingService before making requests. <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 SessionCore_NotificationHandlers.mm : 73 Server returned an error:. Error Domain=NSOSStatusErrorDomain Code=-50 "Session lookup failed" UserInfo={NSLocalizedDescription=Session lookup failed} <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 ... nw_read_request_report [C 1 ] Receive failed with error " No message available on STREAM " nw_protocol_socket_reset_linger [C1:2] setsockopt SO_LINGER failed 22 Debug session ended with code 9: Terminated due to signal 9 Program ended with exit code: 9 Thanks, bvsdev

When i use the MFMailComposeViewController in visionOS, there is no cancel button for the controller. The button at the bottom closes the app. Is anyone else experiencing this? if([MFMailComposeViewController canSendMail]) { MFMailComposeViewController* controller = [[MFMailComposeViewController alloc] init]; controller.mailComposeDelegate = (id <MFMailComposeViewControllerDelegate>)view; [controller setToRecipients:toAddresses]; [controller setSubject:subject]; [controller setMessageBody:body isHTML:isHtml]; [view presentViewController:controller animated:YES completion:nil]; }

I created a minimal sample project that reproduces a microphone issue with nearby SharePlay / Window Sharing on Apple Vision Pro. Sample project: https://github.com/JerryNee/mic-demo Screen recording: https://youtu.be/aMj_A_leJWU Issue I first implemented SharePlay through FaceTime and found that local microphone capture was unavailable. That seemed understandable because FaceTime itself uses the microphone. I then moved the app to a nearby SharePlay / Window Sharing session specifically to avoid a FaceTime call, but local microphone capture still fails. Local microphone capture works before starting nearby SharePlay. After starting a nearby SharePlay / Window Sharing session with GroupActivities, the same app fails at: try audioEngine.start() This does not require a FaceTime call. It happens with an in-room nearby SharePlay / Window Sharing session. The screen recording also goes silent when the Share Window UI appears. I checked the MP4 audio track with ffmpeg silencedetect; audio becomes silent at about 00:00:22.60, matching the moment nearby sharing starts: silence_start: 22.600612 silence_end: 55.051927 | silence_duration: 32.451315 Environment Two nearby Apple Vision Pro devices Xcode device list: visionOS 27.0 and visionOS 26.5 Xcode 27.0, build 27A5194q Frameworks: GroupActivities, AVFoundation, Speech Entitlement: com.apple.developer.group-session Microphone and speech recognition permissions granted Steps Run the sample on Apple Vision Pro. Tap Start Listening and speak. Transcription works. Tap Stop Listening. Tap Start Nearby Session. Share with another nearby Apple Vision Pro. Tap Start Listening again while the nearby session is active. audioEngine.start() fails. Ending the nearby session makes microphone capture work again. Minimal microphone code let recognizer = SFSpeechRecognizer() let audioEngine = AVAudioEngine() let request = SFSpeechAudioBufferRecognitionRequest() request.shouldReportPartialResults = true let session = AVAudioSession.sharedInstance() try session.setCategory(.record, mode: .measurement, options: [.duckOthers]) try session.setActive(true) let input = audioEngine.inputNode let format = input.outputFormat(forBus: 0) input.installTap(onBus: 0, bufferSize: 1024, format: format) { buffer, _ in request.append(buffer) } audioEngine.prepare() try audioEngine.start() Minimal nearby SharePlay code struct MicDemoActivity: Codable, GroupActivity, Transferable { static let activityIdentifier = "com.example.mic-demo.nearby-mic-repro" static var transferRepresentation: some TransferRepresentation { CodableRepresentation(contentType: .micDemoActivity) } var metadata: GroupActivityMetadata { var metadata = GroupActivityMetadata() metadata.type = .generic metadata.title = "Mic Demo Nearby Session" return metadata } } for await session in MicDemoActivity.sessions() { session.join() } _ = try await MicDemoActivity().activate() Questions Is local microphone capture expected to be unavailable during a nearby SharePlay / Window Sharing session? Is screen recording audio expected to become silent during nearby sharing? What is the recommended way to support nearby shared UI/state while still allowing local voice input?

Kind folks, Was all setup for online access to several Q&A sessions at this WWDC, even posted some questions. But other priorities on my project prevented me from attending. Did any of you hear any news on direction finding with 3rd party devices at this year's WWDC? My current understanding is that (for iPhones later than 15) the NI framework returns null for direction. Apple recommends use of the ARkit in conjunction with NI (tech session way back in WWDC22!) FYI, I've been trying hard to get any information on this topic. Would be happy to share what public information/speculation I've found (including how Apple get's such good range and direction info in their Find My app for their AirTag 2 😉). Perhaps we can set up a small discussion group for sharing insights and experiences with emerging UWB technology. Comments appreciated. Mike